[社内勉強会レポート] 『テスト駆動開発』読書勉強会 #9

「テスト駆動開発」読書勉強会

#勉強会

田中賢治

2017.12.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんぬづは、冬休みの課題に「エルゴノミクスキーボードのキーマッピングを良い感じにして、開発効率を爆上げする」という曖昧な目標を立てた田中です。分割キーボードでレイヤーの良い使い方情報など、お待ちしておりますm(_ _)m

さて本題に入っていきましょう。

この会の趣旨

この会の趣旨については、第一回のまとめをご覧ください。

それではまとめていきます。

付録C: TDDからBDDへ

概要

BDDとはなにかと、BDDの歴史がまとめられています。

話し合われた内容

どちらも記号で覚えていて、語彙を変更したことは言葉としての違和感がなかったから先入観を特に持っていなくて、共感できなかった。
- どういう先入観？
Cucumberがなぜ廃れていったんだろう？

付録C: 教条主義化と意味の希薄化

概要

TDDを神的なものとしてあがめることへの批判や、TDDが一般化するにつれて言葉の元の意味が誤解されていっている。一般化にともなってどんな認識のされ方をしているかがまとめられています。

話し合われた内容

このあたりの話は希薄化とともに、誤解もある印象。
ツールや手法を神聖視することは良いことだとは言えないけど、はじめの一歩としては信頼しきるくらいでも良いと思った。
- そこから壁にぶつかるから、使い分けを覚えたり、冷静になってみれたりする。この学習スタンスを良いと思ってる。
アーキテクチャが決め打ちな分密になるが、素早く開発できるRails。素早く開発できることがメリットなのに、無駄に中間層を設けて無理テストを行ったりするのは意図に反している。という話がなるほどと思った。
- 教条主義で、使い分けを考えるべきポイントっぽいと思った。
Test Doubleが広義のモックオブジェクトと広まっていることはあるあるだと思った
test, suite, assertなどの語彙を使っていれば"TDD style"、describe, contest, it, expectなどの語彙を使っていれば"BDD style"という認識が広まった。
- ここを整理すると、図 C.2がわかりやすい。
- 図 C.2の内側のループがTDDで外側のループがBDD。
- 自分が書いて作ったプログラムが正しく動くかどうかをCheckする意味合いが強いのがTDD、受け入れテストとして記述するものがBDD
- "BDD style"って「BDDっぽく」って言ってるのを聞くよね。「アジャイルっぽく」ってフレーズに似てる

付録C: これから

概要

gaiyou

話し合われた内容

写経するとき、手で頑張ってるけど書見台ほしいよねw
もともとSwift(静的型付け言語)で開発していたが、最近はJavaScript(動的型付け言語)で開発している。静的と動的で気にしなければいけないことが変わって、コーディングで重要とする観点が変わるのに気がついている。静的型付け言語だと、入力値になにが入ってくるかわからないのでバリデーションに気を配らなければならないシーンがあったり、なにをどこまで担保するかが人によって変わりそうだという気づきだとか。
TDDが個人のプログラミングテクニックだ、という点に同意。勝手に一人でやってた。
TDDは言語やフレームワークにとらわれず、幅広く使えるスキルなのでとても良い。(特定のツールやフレームワークの使い方を覚えても汎用性がなくて虚しさを覚える自分がいるので余計楽しい)
テストは質を上げない、ということに共感。質を上げていくための、計測ツールだ。
「使いすぎてみて」少し戻ってくるくらいが良い塩梅、ということに共感。
- 初めの一歩として、「なんだかわからないけどとにかくスゴいらしい！」みたいな教条主義になるのは良いと思う。あとでつまづいた時に考え直すから。

まとめ

付録Cを読み終えました。内容はとても理にかなった話をしていっているのに、なぜかエモい気持ちになりました。付録Cで呑める。ここについて意見をまじえると相手がどんなエンジニアなのか垣間見えるかもしれません。

真面目な話としては第一部、付録Cと読んできましたが、チーム開発のはじめに付録Cの読み合わせをしたいなと思いました。自動テストを書く書かない、がっつり書くのか軽く書くのか、どんなスタイルでどこまで踏み込むのか、その判断材料としてうってつけだと思ったからです。もしそこでメンバーがTDDに興味が湧くようであればチームで取り組んでみる、くらいが布教としてちょうど良いかもしれません。機会があれば試してみます！